@youknowriad would you be able to review and give feedback here on the approach, please?

This PR was discussed in Core Editor chat today. See Slack log.

Ryan and I chatted about this PR yesterday. My personal observations are:

As a nice-to-have, I have introduced a new filter to allow the PluginManager class to be filtered

1. I would recommend against adding a new filter as a nice-to-have, and wait until there are compelling use cases.

[emphasis mine] This intermediary makes the API more semantic, allows for future changes/updates more easily

2. The API itself, as far as users or third-party developers are concerned, remains unchanged: its surface consists of the four top-level functions exposed by @wordpress/plugins. From there I have two comments:

• If the API remains unchanged, it cannot be said to become more semantic.
• The choice of data structure or mediator for the data structure doesn’t matter. By “doesn’t matter” I mean that it can be changed at any time with no consequences for the users. However, in this PR we are changing the data structure in order to make future changes hypothetically easier, but we don't yet know what these may be.

3. On the subject of abstractions:

• I’m absolutely in favour of adding the right abstractions to add padding for the future. For instance, @wordpress/element was one such abstraction: in the beginning it was a mere membrane for react, but it allowed us to accommodate changes in React, discourage certain patterns or favour others, experiment with Gutenberg-specific idioms, etc.
• Instead of working on anticipatory changes, I’d focus more on a discussion that can shed light on current limitations of the Plugins API. For instance, as Ryan pointed out, how we can make the API gracefully handle things such as the problems laid out in Plugin sorting via priority property in registerPlugin #16384?

Maybe we can channel the current attention drawn to this PR and to #16384 and attempt to solve a broader problem? It's harder, but it pays off. :)

In the past, we discussed using @wordpress/data store to keep the list of registered plugins. It would mirror what we do with blocks and formatting controls. It has some drawbacks but on the other hand, it brings more consistency and it would help us with re-renders when the list of plugins changes.

I took a gander at this today. Thanks Ryan for taking the time to write this pull and contribute the code. Here's some thoughts I have on this. I also have some thoughts on #16834 which I'll leave as a comment there.

As for this pull, I'm in alignment with what @mcsf has already commented:

1. No filter.

Until there is demonstrable need and it is seen as a valid solution for that need, I don't think we should add filters (or actions). It's nice to think of potential future uses but it is premature to add something that establishes a contract for behaviour which might not be maintainable/ideal in the future.

2. On PluginManager

Generally I like the idea of using an explicit named class/object for registering the plugin against for a couple reasons:

• type checks elsewhere in the code.
• establishing a common interface for interacting with the logic/data represented in the class.

With that said, I agree with @mcsf here that in this case there's no clear benefit for introducing this intermediary class. Functionally it isn't any different than what's in place now. Yes to abstractions, but no to abstractions that have no clear benefit or value over what is present currently. As @mcsf pointed out:

Maybe we can channel the current attention drawn to this PR and to #16384 and attempt to solve a broader problem?

I think you need to identify what is the broader problem that having a PluginManager class solves? I know "semantics" , "precursor to changes in the API", and "allows for future/updates changes more easily" are some rationale given for the introduction of this class but it still seems a bit vague to me.

3. On @wordpress/data store for registered plugins.

I like this idea pointed out by @gziolo , because as pointed out there's a bit or prior art in what is done with managing blocks and formatting controls. It also would be utilizing an established api for interacting with that data. But I think even before implementing something like this, we still should think through identified problems like that raised in #16384 and how we might address them in something like a custom store.

@nerrad thank you for your comments/insight!

I'll remove the filter, it was not required for this PR to function and I agree with the argument of only added it when needed.

To this point:

I think you need to identify what is the broader problem that having a PluginManager class solves? I know "semantics" , "precursor to changes in the API", and "allows for future/updates changes more easily" are some rationale given for the introduction of this class but it still seems a bit vague to me.

This PR is a direct result of the work done for #16384. Specifically this comment. The idea of the API not being semantic enough has been raised a couple of times in Slack in regards to #16384. This PR is an attempt to address that.

As you can imagine, it's starting to feel like we're going in circles a little bit between the two PRs.
While, I'm certainly not looking to rush the correct solution, there just seems to be a lot of push back with very little suggestions as to a course of action that will be acceptable :)

I don't know what's happened but my comment has disappeared from this pull it looks like. Also there's still a lot of changes in the changeset for this pull that don't seem related to the pull itself (there's 258 files changed for my view of this pull). What merge strategy is being used? Maybe there's just something awry with github at the time of me posting this.

It's unfortunate I can't see what I originally wrote in here :(

To address your response to the question I had about what problem this pull solves:

This PR is a direct result of the work done for #16384. Specifically this comment. The idea of the API not being semantic enough has been raised a couple of times in Slack in regards to #16384. This PR is an attempt to address that.

I think what I'm trying to point out by my question is that while I understand the inspiration for this pull, I'm not clear on how this specifically addresses what was raised by the comment in #16384. In part, it's likely because it's unclear exactly what @youknowriad is wanting to see. It appears that in this pull, you feel by moving the plain object into a named class PluginManager that this introduces some meaning to the object. I think what @mcsf and I are getting here is we don't see what additional value this brings as there's really not much difference to the api interface.

As you can imagine, it's starting to feel like we're going in circles a little bit between the two PRs.
While, I'm certainly not looking to rush the correct solution, there just seems to be a lot of push back with very little suggestions as to a course of action that will be acceptable :)

To address this pull specifically. I think there's value on pausing the discussion on gets implemented here until:

• there's a better idea behind what @youknowriad 's had in mind with his comment, since the primary reason for doing the pull was in reaction to that.
• the conversation happening in Plugin sorting via priority property in registerPlugin #16384 arrives at a agreed upon path forward for the problem it seeks to solve. That in turn might be able to inform whether this pull is needed.

the conversation happening in #16384 arrives at a agreed upon path forward for the problem it seeks to solve. That in turn might be able to inform whether this pull is needed.

It looks like #16384 is close to land. @ryanwelcher, if that happens, do you think we still need this proposal?